When managing a network comprising a large number of computers, it is convenient to rely on as few disk drives or disk drive images as possible. Each disk drive or disk drive image contains an operating system (OS) and may contain application programs as well. However, operating systems do not typically support heterogeneous hardware configurations. Moreover, operating systems are typically designed to load on a single hardware platform. As one example, Microsoft OSes do not generally support heterogeneous hardware platforms.
Known methods of supporting multiple hardware platforms with a single disk image all have limitations. For example, one known system stores every needed driver for each hardware platform in the network on a particular hard disk drive (HDD). Such a system typically requires some sort of hardware recognition logic in the OS, such as Plug-N-Play or probing.
However, especially for Windows OSes, the base components loaded by each type of hardware platform need to be the same. This currently prevents using the complete set of features of all the platforms. For example, it is sometimes possible to boot mono-core and multi-core processors from the same HDD (shared or cloned), but only one core would be used by the multi-core processors. Furthermore, it is sometimes not possible to use a single set of base components for all the hardware platforms. Moreover, some recent platforms might have incompatibilities that prevent them from being operated with base components made for earlier platforms, resulting in the requirement to manage several master HDDs or HDD images.
One known solution relates to creating a set of drivers that has the highest degree of compatibility with all hardware platforms in a network. A problem with this approach is that newer features tend to not be supported. For example, if the network includes platforms that are compatible with the Advanced Configuration and Power Interface (ACPI) standard, as well as hardware platforms that are not compatible with ACPI, the ACPI functionality will not function on any system, including the ACPI-compatible systems.
OSes typically provide ways to manually load different configurations. For example, the Windows XP Embedded OS provides a way to specify in a boot descriptor such as the BOOT.INI file which hardware abstraction layer (HAL) and kernel files to use. HAL and kernel properties make it possible for the OS to use numerous features, such as ACPI features, Programmable Interrupt Controller (PIC) features or Advanced Programmable Interrupt Controller (APIC) features, and/or mono-core or multi-core processing capabilities, for instance. However, there is no support for automatically loading the correct set of base components. Moreover, the loading of a correct set of base components is only a manual process that requires user input.
Automating the process of loading base components is not possible at the OS level or boot loader level because the OS is not loaded at all at that time. A software tool known as Windows XP Embedded Target Designer offers the ability to specify a set of drivers that may be used to operate heterogeneous hardware platforms. However, the HAL and kernel files are fixed and cannot be changed. Moreover, one HAL and one kernel file must be specified to be used for the various hardware platforms that will boot a particular instance of Windows XP Embedded or a clone of it. This raises a number of issues, including performance problems and/or incompatibilities that may lead to a need to have several Windows XP Embedded images to deploy and maintain just in order to support two different files. As one example, a HALACPI.DLL file may be maintained for platforms having mono-core processors, and a HALMACPI.DLL file may be maintained for platforms that have multi-core processors.
In Linux/Unix OSes, a compact disk (CD) or digital versatile disk (DVD) may be specially implemented to boot a Linux OS without previously knowing which OS platform is needed for a particular hardware platform. This avoids the need for hardware detection mechanisms. However, such a process is complex and requires extensive software development.